In CloudBees CI in high availability mode, the default behavior of Job.assignBuildNumber (updating a counter in memory, and writing it to disk) is not suitable for rapid build triggers of a single job; an external counter is needed at least transiently (the nextBuildNumber file is fine for a durable count). This beta extension point allows a plugin to swap in an alternate strategy for maintaining the next build number.

The BuildNumberAssignment return type is a bit awkward but I could not think of a better API. Job.saveNextBuildNumber is protected, so not usable from alternate implementations, and I did not want to make it public solely for the benefit of a beta API. (Introducing a public alias also seemed weird.) The method introduced in #9019 does not save, whereas the older updateNextBuildNumber method remains undesirable here because of its call to getLastBuild. Automatically calling saveNextBuildNumber from assignBuildNumber would change sychronization behavior for the default implementation, and making assignBuildNumber be synchronized would be undesirable for the CloudBees CI implementation. Reworked, I hope more clearly.

This PR makes #9778 not strictly necessary but I think it remains appropriate anyway.

Testing done

Effectiveness confirmed by a functional test in CloudBees CI.

Proposed changelog entries

• N/A

Before the changes are marked as ready-for-merge: